Plasma snapp における zk-SNARKs
m0t0k1ch1.icon Plasma snapp の提案の中から zk-SNARKs に関する部分をピックアップ
---.icon
Proving valid state transactions
In this model, the state is described by leaves of the StateMerkleTree. Each leaf is a list of a
このモデルにおいて、state は StateMerkleTree の leaf 群として表現される。各 leaf は以下のリストである。
[public key, amount of token, blockheight of last transfer].
The plasma contract is aware of the current state, as we store it as the variable StateRootHash in the contract.
現在の state は StateRootHash としてコントラクトに保持されるため、Plasma コントラクトはこれによって現在の state を認識する。
State transitions are tracked on the smart contract via the list of StateRootHash es:
state 遷移は、StateRootHash のリストによってスマートコントラクト上で監視される。
StateRootHash_1 -> StateRootHash_2 -> … -> StateRootHash_n.
The plasma contracts also stores the verification keys of the snarks of 3 different programs: P_transfer , P_deposit , and P_exits for 3 different kinds of state changes. These verification keys allow the plasma contract verifying that the state changes for a new block are actually valid ones.
Plasma コントラクトは、3 種類の state 変更に対応する異なるプログラム：P_transfer P_deposit P_exits の SNARKs に対応する verification key も保持している。これらの verification key により、Plasma コントラクトは新しいブロックに対応する state 変更が正当かどうかを検証することができる。
Let us call the program checking the correctness of a state transition based on transfer P_transfer :
transfer に基づいて state 遷移の正しさをチェックするプログラムを P_transfer と呼ぶ。
P_transfer(StateRootHash_i, current block, [witness transactions data]) = (StateRootHash_(i+1))
A transaction is a value transfer from one leaf to another leaf. P_transfer checks the following:
・Leaf of sending account exists
・Leaf of sending account has the needed balance for transfer
・The transfer transaction is signed by the private key associated with the public key stored in the sending leaf and the transaction is intended for the current block height
・Subtracts balance from sending leaf, updates the blockheight of last transfer , updates the StateRootHash
・Leaf of receiving account exists
・Updates balance of receiving leave
トランザクションによって、ある leaf から異なる leaf へ値が移動する。P_transfer は以下をチェックする。
送信元アカウントの leaf が存在するか
送信元アカウントの leaf が transfer に必要な balance を保有しているか
transfer トランザクションが
送信元の leaf に保持されている public key と対応する秘密鍵によって署名されているか
現在のブロック高を示しているか
送信元の leaf の balance が減って blockheight of last transfer が更新され、StateRootHash が更新されているか
送信先アカウントの leaf が存在するか
送信先アカウントの balance が更新されているか
The witness transaction data will be used by the snark proof, but they will never touch the rootchain. It is only needed to create once the witness of the snark.
witness transaction data は SNARK proof によって使用されるが、それらは決して root チェーンに触れることはない。SNARK の witness を一度生成するためだけに必要。
m0t0k1ch1.icon オペレータが Plasma コントラクトに提出するのは witness と proof なので、[witness transaction data] は root チェーンに提出されるデータではない
This is pretty straightforward. But how do we make the plasma chain aware of deposits and withdrawal? We think the following trick will do the job:
ここまではとても単純だが、Plasma チェーンが deposit や withdrawal に気づくようにするにはどうしたらよいだろう？我々は、以下のようなトリックが使えると考える。
The information of several deposits, which are sent to the plasma contract, can be hashed together to a DepositHash by the plasma contract. By requiring the snark proof to take the DepositHash as a public variable, we can enforce the snark proof to process all deposits.
Plasma コントラクトに送られたいくつかの deposit に関する情報は、Plasma コントラクトによってまとめて DepositHash に変換される。SNARK proof が公開情報である DepostiHash を引数とすることを要求することで、SNARK proof が全ての deposit を処理することを強制する。
The program P_deposit checking the correctness of deposits would look like this.
deposit の正しさをチェックするプログラム P_deposit は以下のようになる。
P_deposit(StateRootHash_i, DepositHash_i, [witness deposit data]) = (StateRootHash_(i+1))
A deposit is a value transfer into an empty leaf. Whether a leaf is empty, we will store on the ethereum mainchain in a mapping: leafOccupation . P_deposit does the following:
・Insert public key and deposit amount into the leaf
・Updates the StateRootHash
deposit は空の leaf への transfer となる。leaf が空であろうがなかろうが、メインチェーンである Ethereum で leafOccupation マップに格納する。P_deposit は以下を行う。
公開鍵と deposit 量を leaf に挿入する
StateRootHash を更新する
The same can be done for exits: All exit requests can be collected by the plasma contract. The user submits the exit request to the plasma contract by submitting his address and the height at which he would like to withdraw. This height is in most cases the first unavailable block. The operator is required to react upon each exit request by submitting the withdraw-able balance of the requested height from the plasma chain. Then these information [address, balance, StateRootHash of block of height for request] are hashed together in an ExitRequestHash and by making it a public input the snark, we can enforce the snark to process this exit request.
exit についても同様。全ての exit 要求は Plasma コントラクトに集約される。ユーザーは、自身のアドレスと引き出し元となるブロック高を提出することで、Plasma コントラクトに exit を要求する。ほとんどの場合、このブロック高は最初の unavailable なブロックに対応する。オペレータはこれに反応し、各 exit 要求で指定されたブロック高において Plasma チェーンから引き出し可能な残高を提出しなければならない。これらの情報 [address, balance, StateRootHash of block of height for request] はまとめて ExitRequestHash に変換されて SNARK の公開入力となるため、SNARK に対して exit 要求の処理を強制できる。
m0t0k1ch1.icon 最初の unavailable なブロック：次に追加されるブロック、ってことかな？
P_exit(StateRootHash_i, ExitRequestHash_i, [witness exit data]) = (StateRootHash_(i+1))
A withdrawal tries to exit all balance out of a leaf. The snark checks the following:
・Leaf has not sent out a transaction in the last 40k transfer blocks (equals 7 days) or withdrawal balance is 0
・Leaf stored exactly the predefined balance at the specific height or withdrawal balance is 0.
・Either the leaf in the latest state does not have a higher block height of last transfer as the block height, from which we are currently withdrawing or withdrawal balance must be 0.
・Deletes the complete leaf, updates StateRootHash
withdrawal は leaf から全ての残高を exit しようとする。SNARK は以下をチェックする。
leaf が直近 40k transfer ブロック（7 日分に相当）の間にトランザクションを送信していないか（そうでなければ引き出し可能残高は 0）
leaf が、ある特定のブロック高における残高を正確に保持しているか（そうでなければ引き出し可能残高は 0）
最新の state に含まれる leaf は、現在引き出そうとしているブロック高より高い block height of last transfer を保有していないか（そうでなければ引き出し可能残高は 0）
処理済みの leaf が削除され、StateRootHash が更新されているか
Unfortunately, exits with a fraction of the balance are not supported by this protocol.
残念ながら、このプロトコルでは残高の部分的な exit はサポートされていない。
Note that the operator needs to set the withdrawal balance, as only he knows for sure the current balance. Still, the snark enforces the operator to set the correct balance, as otherwise he will not be able to find a proof. If someone makes an exit request, which is not valid, the operator will set the balance in the exit to 0. Exit request against non-occupied leaves is prevented by the plasma smart contract.
現在の残高を確実に把握しているのはオペレータだけなので、オペレータが引き出し可能残高を設定しておく必要があることに注意する。なお、SNARK はオペレータが現在の残高を設定することを強制している。そうでなければ、オペレータは proof を見つけることができない。誰かが不正な exit 要求を生成した場合、オペレータは exit 量を 0 にする。保有していない leaf に対する exit 要求は Plasma コントラクトによって妨げられる。
These three different programs allow the operator to append the plasma chain with 3 different block types (deposits, transfers and exits) by sending over the respective snark prover key. The plasma smart contract would enforce that registered pending exits would be processes at first, forcing the operator to submit exit blocks, before deposit or blocking transfer blocks. Likewise, if there are deposits pending for several blocks, then the plasma contract would force the plasma operator to include deposit blocks before any transfer blocks are accepted. Only if there are no pending deposits or withdrawals, then the plasma chain allows appending transfers blocks.
これら 3 つの異なるプログラムにより、オペレータは、それぞれの SNARK prover key を送信することで、Plasma チェーンに 3 つの異なるブロックタイプ（deposit、transfer、exit）を追加することができる。Plasma コントラクトは、登録された保留中の exit が優先で処理され、オペレータが exit ブロックを提出することを強制する。これは deposit ブロックや transfer ブロックの提出よりも優先される。同様に、保留中の deposit がある場合、Plasma コントラクトは、transfer ブロックを承認するよりも先に deposit ブロックを含めることをオペレータに強制する。保留中の deposit や withdrawal が存在しない場合のみ、Plasma チェーンに transfer ブロックを追加できる。
m0t0k1ch1.icon ブロックが 3 種類ある（deposit ブロック、transfer ブロック、exit ブロック）
m0t0k1ch1.icon Plasma コントラクトに提出する優先順位は「exit ブロック > deposit ブロック > transfer ブロック」で、これは Plasma コントラクトで規定する